CIP-0138? | Universal Query Layer #869
Conversation
CIP-XXXX/README.md
Outdated
|
|
||
| Response: | ||
|
|
||
| - `TransactionUnspentOutput[]` |
There was a problem hiding this comment.
CIP-0116 defines this to include a TransactionOutput with this schema: https://github.com/cardano-foundation/CIPs/blob/b81611632f9dcea0b87d7d96cf673a720c77e929/CIP-0116/cardano-babbage.json#L445C6-L445C23
I would like to point out that chain data APIs seemingly do not decode the datum by default, i.e. when responding with transaction outputs.
I just stumbled over this yesterday in Hydra, which uses the cardano-api library to encode TxOuts and that results in a decoded datum mapped to json equivalence. See also our (messy, sorry) api reference: https://hydra.family/head-protocol/unstable/api-reference/#schema-TxOut
rphair
changed the title
Update README with Transports section and full list of methods
|
thanks @nazrhom - editors note to also tag you on discussions related to this CIP. |
There was a problem hiding this comment.
thanks @klntsky @nazrhom - marking Triage so this is officially brought into the review process at next CIP meeting (https://hackmd.io/@cip-editors/100) and my vote would be that a CIP number gets assigned there.
In the meantime we have to remove the bits of the CIP template scaffolding identified below:
rphair
added
the
State: Triage
|
Thanks @rphair |
rphair
changed the title
There was a problem hiding this comment.
@klntsky @nazrhom proposal well received & confirmed as candidate at last CIP meeting. Please remember to rename the proposal directory accordingly & update the README link in the original posting. 🎉
one question @nazrhom ... I had assumed the .json files here illustrative examples, but if they are implementation files (therefore likely to require maintenance beyond the CIP) the recommendation is to host them in a repository that you and/or implementors will maintain. Please confirm which category these are in (apologies if you've already done that & I missed it).
rphair
added
State: Confirmed
| - [ ] There is at least one protocol adapter for any of the existing query layers that implements this spec, that can be run. | ||
| - [ ] There is at least one offchain library that implements a provider interface for this CIP, effectively making it usable with the protocol adapter in production. |
There was a problem hiding this comment.
I think this should be at least two. To show actual adoption across tooling. Otherwise we rapidly end up with 10 different Universal Query Layer (cf famous XKCD I don't need to link to because everyone knows what I am referring to).
Also, given the pre-existence of well established API query layers in the ecosystem already, I would definitely consider gathering maintainers around a table to discuss this. Standardization will likely not happen unless the top players commit to it as well.
There was a problem hiding this comment.
yes & please also @klntsky @nazrhom invite any potential implementors you are aware of to participate via the "table" at the CIP Discord > #query-layer-standard (invite).
A transport-agnostic query layer specification for use in dApps and wallets.
See CPS-12 for motivation.
(rendered version)